1. Field of the Invention
Embodiments of the present invention generally relate to computer graphics and, more specifically, to optimized 3D lighting computations using a logarithmic number system.
2. Description of the Related Art
Three-dimensional (3D) graphics systems are typically architected around a graphics pipeline that includes computational infrastructure designed to respond to commands received through an application programming interface (API) layer. A graphics application generates commands and passes the commands through the API layer using a set of predefined function calls, also known as “API calls,” to invoke specific functionality defined by the API. The implementation details of this functionality are generally opaque to the application and may include software, hardware or a mix of both hardware and software. The API calls generated by the graphics application are configured to adhere to the API specification requirements, including the specific data structures and data types that the application passes to the API when invoking the different API calls. Many APIs specify data values in one or more conventional arithmetic types. Conventional arithmetic types include standard 32-bit floating-point, 32-bit fixed-point and 32-bit integer. Longer and shorter variations thereof are also conventional arithmetic types. For example, a 16-bit fixed-point type and a 64-bit floating-point type are both conventional arithmetic types. The API calls related to lighting computation are commonly invoked using one or more conventional arithmetic types.
Generally, lighting computations occur early in the graphics pipeline. Lighting computations are also one of the most computationally expensive stages within the graphics pipeline. Certain high-end graphics processing units (GPUs) include the lighting computation portion of the graphics pipeline. However, many low-cost or low-power GPUs do not include this functionality and instead rely on the host central processing unit (CPU) to perform lighting computations. When performing lighting computations, the CPU typically executes floating-point math instructions such as division, reciprocal and square root using a hardware-based floating-point unit, if such a unit is included in the CPU. However, in many low-power mobile computing devices, such as cell phones and personal data assistants (PDAs), the host CPU does not include a hardware-based floating-point unit since these units are relatively expensive CPU resources. Instead, CPUs found in mobile computing devices more commonly include only an integer math unit, which is typically not configured to perform division, reciprocal and square root operations.
Without floating-point math hardware, a software-based math library is used to support conventional arithmetic data types within the math functions used by the lighting computation stage of the graphics pipeline. The operating system, the compiler, or the API layer may supply the software-based math library. The software-based math library is built from a set of integer math instructions provided in hardware by the CPU's integer math unit. Dozens of integer math instructions are typically executed to complete certain types of conventional arithmetic math operations. For example, using integer-based software that is optimized for the well-known ARM™ instruction set, approximately 55 integer instructions are executed to perform a single floating-point addition or subtraction operation. Similarly, approximately 90 integer instructions are executed to perform a single floating-point division operation. The overall performance of the graphics pipeline is therefore substantially reduced in systems that need to perform complex computations, such as lighting computations, but do not have a dedicated floating-point unit in hardware.
One solution to the performance reduction associated with software-based floating-point math is to use fixed-point integer math instead. However, many APIs specify a dynamic range that is much wider than the range that fixed-point math can easily accommodate. For example, the 3D graphics glue layer for Java™, commonly referred to as JSR-184, requires that certain key lighting computations (including normal transforms) be performed in an arithmetic that provides a dynamic range of 2−64 to 263, with 16 bits of precision. In addition, the API corresponding to JSR-184 specifies that applications deliver data to the 3D graphics software in the well-known 32-bit IEEE-754 single precision floating-point format. Such constraints make implementing a fixed-point arithmetic that satisfies the JSR-184 requirements largely impractical. Certain applications substantially utilize the full dynamic range and may generate visual artifacts if the dynamic range is not supported in the underlying arithmetic functionality.
As the foregoing illustrates, what is needed in the art is an improved arithmetic system for performing software-based conventional arithmetic operations that can be effectively implemented in computing devices, such as mobile computing devices, that do not have a hardware-based floating-point unit in the host processor.